NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/4520

Text File | 1996-08-05 | 8.9 KB | 186 lines

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.c
Subject: Re: void main() and other atrocities!
Date: 04 Feb 1996 19:04:33 GMT
Organization: Los Alamos National Laboratory
Message-ID: <[e-mail]>
References: <4eduaj$[e-mail]> <4epplj$[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: [e-mail]'s message of 4 Feb 1996 09:44:49 -0800

In article <[e-mail]> [e-mail]
(Kazimir Kylheku) writes:
<snip>
   >    AxCrnA$ cc test.c
   >
   >    void main() {exit(0);}
   >    .....^
   >    %CC-E-NEEDNONVOID, In this statement, "main(...)" has void
type, but occurs
   >    in a context that requires a non-void result.
   >    at line number 2 in file DISK$L32:[DANPOP]TEST.C;3

   I know that it would break a compiler that generates an incompatible linkage
   for functions returning int and void functions (assuming that the
function you
   are calling does not return). But I just don't know of any that do (and it
   would be silly to write one that generates subroutine linkage code
which breaks
   when a void function is called that is assumed to be int).

You just saw above a compiler that does complain. In fact, more and
more compiler technology is moving from `let the user do whatever
(s)he wants' to `let us be helpful and give warnings for all
questionable behaviour'. This may take away the `charm' of programming
for old timers, who like the frontiersmen loved a reckless dangerous
way of life; but, I do not think that anyone is their sane mind would
deny it makes for better software tools. Now that we are a generation
which has finally learned how to program the clock on the vcr,
computers are slowly but surely advancing from machines that had to be
treated with oh-so-much-awe to as much items of daily use as
microwaves. Being smarter, we expect them to warn when we do something
wrong ... this is the new wave. Nostalgia for the past is common, but
that cannot hold back progress. In fact, it doesn't: like it or not,
change comes; and one needs to adapt to survive.

With that prologue, I can think of one very important reason why the
declaration of main must be int main and _not_ void main. The issue is
type safe linkage. In fact, I always wondered why a computer was not
smart enough to detect that a called entity cannot be the defined
entity simply because they have different types! In a type safe scheme,
the os will call an int main(int argc, char*argv[]), failing which it
will call an int main(void) failing which it will abort! (one possible
implementation: another would be that a library provides a
non-overriding int main(int argc, char*argv[]) which calls an
undefined int main(void);).

Sure, void main could have been included in that list. But, the point
is that the language was specified with a `return code' in mind. Main
is _supposed_ to return an integer valued code specifying whether
there was an error. This is supposed to be the main means of
specifying the return ... giving it a void type is, I believe,
philosophically incorrect. The reason exit exists in the first place
is because there is little facility of exception handling in C
... with proper exception handling mechanism, one probably wouldn't
even need it.

   It's also atrocious that main() has to be treated as a special language
   construct, and that a call to exit() in main() (when it is the last
statement)
   is to be identical to a return.

What you are complaining about is not that main has to be treated
specially: it is natural that it has to be. A program is initiated by
the OS, and the OS needs to know how and what to initiate! If you
declared main as `struct foo main(float x)', how _can_ the OS know
what float it is expecting, and what to do with its struct return?
Your objection is basically to the use of exit as the last statement
to terminate main: and I agree this is a barbaric practice. exit
should be used to exit from somewhere deep in the code, or to avoid
complicated control structures. `goto's, multiple `return's, any
`longjmp', `break's in loops and fall thrus in switch and `continue's
as well as `exit' are all contrary to structured flow control: there
use should be carefully monitored.

A real language is a compromise between the different principles in
what we currently know as good software engineering principles: a
program is maintainable if it is simple, and it is maintainable if it
is structured. As the two goals sometimes conflict, a succesful
language specification can not take a purist stand. exit is necessary,
and whether one likes it or not: it is.

   I don't advocate that people declare main() to return void (in fact
I don't do
   so myself), but I don't see it as some sort of big mistake. In my
own coding, I
   sometimes even define the argv/argc parameters even if I don't use
them, just
   to meet the implicity prototype.

Actually, the standard specifically chose to allow int main(void), so
you do not need to specify argc, argv. Logically, I believe this is a
mistake: but standardizing a language which has already been in use by
various people on differring architectures is a difficult task. A few
compromises were made: that is unfortunate, but, I believe they are a
historical necessity.

   I did read the relevant section in the FAQ. It is merely concerned with the
   issue of eliminating compiler warnings stemming from calling exit()
in main()
   despite a "void" declaration thereof. The issue that a void function may
   not be compatible with a call to an int function doesn't seem that
significant,
   since nobody in their right mind would design a compiler that way.

Yes, they would. There are reports that a Toshiba Satellite T2400CT
with a 486/66 running  Windows 3.1.1 fails during link if one uses
void main. I guess it is trying to do some kind of type safe
linkage. As I am not sure of these reports (I belong to the old
school where I trust myself and no one else :-), I cannot say more
about this. I do however see reasons why a compiler writer will make
the distinction.

   In any case, I program using ANSI C only about 30% of the time. The
   old-fashioned function declarations are more elegant. The only truly useful
   thing introduced in ANSI C is the standardization of
variable-length arg list
   handling.  It's the only thing I really miss when working with non-ANSI
   compilers. The other things I can handle myself: for instance, I
don't need the
   compiler promoting arguments to their prototyped types for me. An
explicit cast
   is more conscientious.

The main purpose of prototypes is not merely to do automatic
promotions. The main point in their favour is that they allow the
compiler to do more extensive consistency checks more easily. They
take away the need for many casts which are potential sources of
error. In other words they make for simpler expressions of an
intuitive structure of algorithms which puts more burden on the
compiler than on the code writer. This is what I consider the wave of
the future.

   There is something magical about the old-style C that attracts me. I can't
   quite put my finger on it. I was once a very good, careful coder. I
wrote neat
   programs in Modula 2 and similar langauges, always had carefully designed
   abastract data types. All my cardinal variables belonged to
carefully declared
   and typed domains, arrays had typed ranges, etc.  It all went down hill from
   there!

   Now I'm increasingly catching myself writing assembly code, as though I had
   gone full-circle. The arguments of what a main() function ought to be sound
   like the buzzing of flies to me.

As I said, things change. I believe what you are facing is what is
called a `paradigm shift' in today's world of jargon. The job of a
programmer today is not to micro manage the details, not to get that
one extra cycle that can be had, but to write clear maintainable code
whose beauty is not in its cleverness of register manipulation but in
its abstract mathematical algorithmic structure.

   Can someone else identify with me? :)

I am sure many do. That, fortunately or otherwise, changes
nothing. One way of thinking gives way to another, whether we like it
or not. It is the exact same tautology of evolution: the structures
and patterns of thought which are inherently most fit to survive, do
survive best.

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]